\section{Fazit}
Die Arbeit, von der Aufgabe mit Aufgabenanalyse (in Kapitel \ref{chap:Introduction}), der Implementierung der Applikation (in Kapitel \ref{chap:appOverview}) bis zur Zeitmessung zwischen \gls{CPU} und \gls{GPU} (in Kapitel \ref{chap:Measure}) ist damit abgeschlossen.\\
\\
Texturen mit einer Matrix zu filtern, wird mit der \gls{GPU} effektiver gelöst. Je mehr Elemente in der Matrix verwendet werden, desto stärker wächst der Vorsprung gegenüber der Filterung mit der \gls{CPU}. 

\section{Verbesserungsvorschläge}
Folgende Problemstellungen sind nicht gelöst:
\begin{itemize}
\item Rendern mit der GPU ohne SurfaceView
\item Daten in die GPU laden, ohne den Shader neu zu kompilieren
\end{itemize}
Wenn dieses Framework mit der Basisklasse \textit{BaseFrame} verwendet wird, muss zwingend eine SurfaceView angefordert werden. Der Render-Prozess startet mit der Anfrage der SurfaceView. Dieses Konzept ist so gewählt, weil die Methode onDrawSurface in der \textit{GL20Renderer}-Klasse vom System aufgerufen werden muss. Recherchen haben ergeben, dass dies mit einem eigenen \textit{Thread}, welcher die \textit{onDrawSurface}-Methode aufruft, gelöst werden kann. Eigene Tests im Vorfeld konnten dies nicht bestätigen.\\
\\
Die in der Arbeit entwickelte Applikation durchläuft beim \gls{GPU} Rendering immer den kompletten Prozess. Es werden Sourcedaten geladen, kompiliert, gelinkt und Texturen geladen. Ein Optimierungsvorschlag ist, das Kompilieren der Sourcedaten nur vorzunehmen, wenn die Konfiguration angepasst wird. Bei der Änderung der Anzahl Kernel Elemente ist eine Neukompilierung notwendig.\\
\\
Das Rendern mit der CPU ist in den folgenden Bereichen nicht vollständig analysiert:
\begin{itemize}
\item Optimierter Datentyp für die Berechnung, wie zum Beispiel \textit{byte}
\item Minimierung der Speicherzugriffe
\end{itemize}
Auf der Website von Android Develper \cite{Android2012} finden sich unter dem Link \textit{Code Guideline} Design-Tipps.
